被低估了的数字化方法论 ｜ IBM车库方法
我在三年前的《“数字化创新”与“数字化转型”的区别》文章中就提到过IBM的数字化创新方法论“IBM车库方法”（ Garage Methodology），三年过去了，在国内数字化转型领域里，这套方法论明显没有被广泛传播，我觉得它作为企业开展数字化创新，创造数字化产品的体系性、实操性的方法，在中国数字化转型界被严重低估了。
有些朋友没有理解为什么叫“车库”方法——美国人几乎家家户户都有车库，有人喜欢在车库里鼓捣各种修理工具，很多创新发明都是车库里搞出来的，例如惠普、苹果等硅谷公司都是在车库里创业的，参见《车库法则的传承》，所以“车库”就是技术创新的代名词。
就像ERP时代，SAP ERP实施产生了“ASAP方法论”，几乎确立了大型企业软件的实施方法论标准。IBM 车库方法论是一套从数字化驱动的组织文化总体转型，到基于云的数字化产品创造的端到端方法，其特点是：
基于用户体验，是企业级的设计思维方法
揭示了如何紧密衔接分布式或集中式的数字化产品团队
利用DEVOPS工具/技术以及云平台进行持续交付
赋能站点可靠性工程（SRE）
快速迭代，交付业务价值
提升数字化人才和组织文化
企业级（而非小组级或产品级）的数字化创新
“数字化转型”这个名词提出这么多年来，我较少看见全球技术公司提出这样体系完整、同时又完全对用户开放的方法论体系——有些国际云大厂虽然也有类似方法论，但是体系性和用户开放性都还不够，有些技术咨询公司的数字化产品方法论显得过于技术。
国内的几家云大厂更是缺乏这样完整的方法论体系，也没有把自己的云服务以及DEVOPS工具和方法论体系进行包装。中国的数字化转型口号喊得响，各种大而化之、商业化的概念包装多，而在数字化实操的方法论总结上，对于创新流程、技术工具、组织变革以及工作方式上的关注都是不够的！不得不承认，在IT产业中，中国的信息技术应用的方法论建设和国外同行相比，还有很大差距！
数字化创新之核心是创造“数字化产品”，和传统开发信息系统相比，无论是产品开发组织的工作形式、开发过程、所使用的技术工具（关键技术包括：云计算、混合云、人工智能、容器、容器管理平台、DevOps工具等），还是企业开发数字化产品的组织变革（设计师、架构师、工程师、数据科学家、业务战略师、产品经理等多专业协作，multidisciplinary expertise）、组织文化（关键组织文化特质包括敏捷组织、创新文化等）都有显著不同。
IBM车库方法是设计思维、敏捷开发以及Devops技术的整合，它包含了数字化产品开发流程、相关最佳实践：
发现（discover）：挖掘商业机会，确定产品开发方向
展示（envision）：最小可用产品（MVP）设计
开发（develop）技术开发的架构、代码、测试、部署
智慧（reason）：大数据和人工智能应用
运营（operate）：高可用的数字化产品运营
学习（learn）：用户体验反馈和产品持续改进
文化（culture）：敏捷文化和敏捷组织运行
这套方法还推荐了一系列IBM自有以及第三方的数字化工具来支持这些流程和实践。以上述“文化”为例，推荐了敏捷组织常用的数字化工具：代码管理Github、协作工具Slack、白板工具Mural、看板工具Trello、存储平台Box以及电话会平台Webex等：
虽然这套方法论是IBM发明的，但是可以作为普适的数字化创新方法。推荐的工具可以使用用户自己习惯使用的工具来替代，例如：
车库方法推荐工具 | 替代工具示例 | |
代码管理 | Github | Gitlab |
协作工具 | Slack | 飞书, Discord |
白板工具 | Mural | Miro |
电话会 | Webex | 腾讯会议, Zoom |
看板工具 | Trello | Canny |
存储 | Box | Dropbox |
IBM 车库方法论是2016年左右跟IBM云业务（IBM Cloud）同步产生的，然而IBM的公有云业务落地中国却是命运多桀，这也许是这套方法论没能在中国得以普及的重要原因。让人觉得遗憾的是，这套方法论尽管在美国已经推出了好几年了，但是IBM中文官网上仍然没有方法论文档完整的中译版本，而且中文网站上对“车库创新”的中文解释和原意也有很大偏差。
由于这套方法论的通用性，我非常希望看到中国云厂商也能够包装出类似的方法论体系，来指导中国的数字化创新。
最后特别说明，本文非IBM车库方法论的官方解释，仅为作者个人研究心得；原文请访问网站：https://www.ibm.com/garage/method